前言
在臨床護理流程中，護理師每班最核心的工作之一就是量測與記錄生命徵象（Vital Signs, 俗稱 TPR：體溫 Temperature、脈搏 Pulse、呼吸 Respiration，以及血壓 Blood Pressure）。傳統護理表單或封閉系統常將這些數據簡單記錄為純數字：例如 temp: 38.2、bp: 135/85。

然而，當這些數據需要跨系統分析或交換至電子病歷（EMR）時，若缺乏明確的上下文語意，就會引發嚴重的歧義：
1.38.2 的單位是攝氏還是華氏？量測部位是耳溫、腋溫還是肛溫？
2.血壓由收縮壓與舒張壓兩個數值組成，要如何用結構化模型精確表達？
3.系統該如何讓機器自動識別這是一筆「體溫」而非「體重」？

在 HL7 FHIR 中，所有臨床觀察、檢驗數值與生命徵象統一由最核心的 Resource——Observation 進行塑模，並透過國際標準編碼系統 LOINC（Logical Observation Identifiers Names and Codes） 確立語意。

一、什麼是 LOINC 編碼？
LOINC 是全球醫療領域用於識別臨床實驗室檢驗與健康觀察數據的通用編碼標準。每個代碼由 3 至 7 位數字加上連字符與校驗碼組成。

在護理生命徵象（Vital Signs）實務中，幾個最常使用的 LOINC 代碼如下：

二、Observation Resource 核心結構拆解
一個合規的 Observation 主要由以下關鍵要素構成：

1.status：記錄狀態，生命徵象通常為 final（正式確認）或 preliminary（初步量測）。
2.category：分類標籤，生命徵象必須帶入系統代碼 vital-signs。
3.code：採用 LOINC 編碼宣告這筆觀察究竟是什麼項目。
4.subject：關聯的病患（參照 Patient）。
5.effectiveDateTime：量測發生的確切臨床時間點（ISO 8601 格式，含時區）。
6.performer：執行量測的醫護人員（參照 Practitioner）。

數值表示方式：
-單一數值 (valueQuantity)：用於體溫、脈搏等單一量化指標，需包含數值（value）、單位（unit）、系統（system：UCUM 國際統一計量單位）與代碼（code）。
-複合數值 (component[])：用於血壓等由多個子指標組成的觀察。

三、實戰 JSON 範例
範例 1：單一生命徵象（耳溫量測）
以下展示一筆標準的體溫記錄，額外加入了量測部位（bodySite，使用 SNOMED CT 編碼表示耳溫）：

範例 2：複合生命徵象（血壓量測）
血壓不能直接填入單一 valueQuantity，而是透過主 LOINC 85354-9 搭配 component 陣列拆解收縮壓與舒張壓：

四、異常判定與參考範圍：referenceRange 與 interpretation
在行動護理系統中，當病患體溫高於 38.0°C 或收縮壓高於 140 mmHg 時，系統介面必須即時亮起紅字或跳出警示。

FHIR 的 Observation 原生支援兩種欄位來傳遞此類資訊：
1.interpretation：由量測系統或判讀演算法給予的定性結果（採用 HL7 v3 Code System）：
-H：高於正常（High）
-L：低於正常（Low）
-A：異常（Abnormal）
-N：正常（Normal）
2.referenceRange：提供該項目的臨床參考區間（例如正常成人體溫介於 36.5°C 到 37.5°C 之間）。

小結
今天我們徹底解構了臨床數據傳遞的通用載體 Observation：
1.掌握了以 LOINC 為核心的國際編碼映射與 UCUM 統一計量單位。
2.釐清了單一數據（valueQuantity）與複合數據（component，如血壓）的結構差異。
3.了解如何透過 interpretation 與 referenceRange 傳遞臨床異常標記，為後續的臨床早期預警引擎打下資料基礎。

至此，我們已經熟悉了三大核心 Resource（Patient、Practitioner、Observation）。明天 Day 5，我們將動手實踐：使用 Docker 架設在地化 HAPI FHIR 測試伺服器與 PostgreSQL 資料庫，準備在本地端發出人生第一支 FHIR API 請求！